[00:05.050 --> 00:08.910]  It's like somebody else already has control over the stream.
[00:09.990 --> 00:14.530]  Oh, there it went. Now it's still doing the thing.
[00:17.860 --> 00:19.360]  And there we are.
[00:19.360 --> 00:21.520]  And there we are. All right.
[00:21.520 --> 00:24.720]  Welcome back. So we have another session.
[00:24.720 --> 00:28.700]  This time is going to be with our friend here, Jack Baker.
[00:28.700 --> 00:29.400]  Welcome, Jack.
[00:30.080 --> 00:31.960]  Thank you. Glad to be here.
[00:31.980 --> 00:34.980]  All right. And also we've got Fallible here as well. Hey, Fallible.
[00:35.140 --> 00:36.000]  Hello.
[00:36.000 --> 00:40.800]  So Jack was going to tell us a little bit,
[00:40.800 --> 00:42.720]  at least he did tell us a little bit in his presentation,
[00:42.720 --> 00:46.100]  about how he kind of attacked game servers.
[00:46.420 --> 00:49.200]  Jack, do you want to kind of give a little bit of an introduction of yourself
[00:49.200 --> 00:51.520]  and just kind of a super brief overview of your talk
[00:51.520 --> 00:55.500]  so that other people might get more interested in it as well,
[00:55.500 --> 00:58.060]  on top of some of the other questions that we're already seeing
[00:58.060 --> 01:00.260]  in the TrackOne Live QA channel?
[01:01.060 --> 01:02.360]  Yeah, for sure.
[01:02.360 --> 01:04.660]  So my name is Jack Baker.
[01:04.660 --> 01:07.960]  I don't have much of a background to talk about.
[01:08.220 --> 01:10.760]  This is my second time speaking at DEF CON.
[01:10.760 --> 01:13.560]  Both times have been about hacking video games.
[01:14.120 --> 01:16.740]  And for my talk this year,
[01:16.740 --> 01:20.380]  it was basically about finding bugs in game engines.
[01:20.380 --> 01:22.760]  So basically looking at the core software
[01:22.760 --> 01:24.860]  that you build video games on
[01:24.860 --> 01:27.240]  with the hope that finding bugs in the engine
[01:27.240 --> 01:29.760]  means finding bugs in a thousand different games,
[01:29.760 --> 01:32.780]  basically amplifying that effort.
[01:32.780 --> 01:36.340]  So I had a reasonable amount of luck
[01:36.340 --> 01:40.300]  looking at Unreal Engine 4 from Epic Games
[01:40.300 --> 01:44.900]  and UNet, the core networking protocol of Unity.
[01:45.200 --> 01:48.020]  And I talk about four of those bugs.
[01:48.920 --> 01:54.460]  And I give some POCs, typical DEF CON stuff, I guess.
[01:54.460 --> 01:57.140]  Yeah, it was all pretty awesome stuff in there.
[01:57.140 --> 02:00.840]  Falvo, do we have any questions coming in yet for Jack?
[02:00.840 --> 02:03.240]  We have a very first question over here.
[02:03.240 --> 02:05.760]  I like this one. This is from Hawkeye Dank.
[02:06.480 --> 02:09.660]  Do you believe that most game servers slash developers
[02:09.660 --> 02:13.420]  are heading towards a zero-trust architecture for newer games
[02:13.420 --> 02:16.940]  in order to better protect the game servers?
[02:17.960 --> 02:19.660]  That is a good question.
[02:19.660 --> 02:21.660]  So I would actually argue that to some extent
[02:21.660 --> 02:23.180]  that has already been done.
[02:23.180 --> 02:26.480]  If I were to go back a bunch to when I was a teenager
[02:26.480 --> 02:28.560]  trying to learn to hack video games,
[02:28.560 --> 02:30.980]  I remember that there was sort of this philosophy
[02:30.980 --> 02:34.820]  that the only online game you really couldn't hack
[02:34.820 --> 02:36.640]  was RuneScape.
[02:36.640 --> 02:39.680]  And the reason for that is RuneScape is about as close
[02:39.680 --> 02:42.400]  as you'll get to just a pure thin client
[02:43.560 --> 02:45.640]  in a big video game.
[02:45.640 --> 02:48.660]  And so you couldn't really manipulate the client
[02:48.660 --> 02:50.820]  to do things like teleport or whatever
[02:50.820 --> 02:54.740]  because it was just basically just button presses.
[02:54.740 --> 02:59.160]  In that case, though, people still managed to
[02:59.160 --> 03:01.040]  quote-unquote hack RuneScape,
[03:01.040 --> 03:03.000]  but it was in the form of logical bugs.
[03:03.000 --> 03:06.860]  It wasn't trust being placed on the client.
[03:06.920 --> 03:09.320]  So to answer that question,
[03:09.320 --> 03:12.640]  I think that you absolutely can make a zero-trust
[03:13.520 --> 03:14.920]  game engine as is,
[03:14.920 --> 03:19.120]  but you're balancing performance and security.
[03:19.120 --> 03:21.200]  And if you go too far on the security side,
[03:21.200 --> 03:23.120]  you end up with a game like RuneScape,
[03:23.120 --> 03:27.860]  which is very low, very slow,
[03:27.860 --> 03:30.280]  with not a whole lot going on.
[03:30.280 --> 03:32.940]  It's very difficult to apply that to something like,
[03:32.940 --> 03:36.300]  I don't know, Fortnite, where you've got a thousand,
[03:36.300 --> 03:39.120]  no, I guess a hundred people shooting guns.
[03:39.120 --> 03:40.860]  You've got all this math going on.
[03:40.860 --> 03:43.520]  It's just a different scale of a problem.
[03:43.520 --> 03:47.120]  But we're getting much better at it.
[03:47.120 --> 03:49.480]  Game engines have gotten significantly better
[03:49.480 --> 03:51.640]  at taking that trust away.
[03:51.640 --> 03:54.960]  So yeah, I think that's where things are going to keep moving,
[03:54.960 --> 03:58.980]  is taking that trust away and finding clever ways
[03:58.980 --> 04:04.100]  to make servers that can still handle a first-person shooter,
[04:04.100 --> 04:05.620]  still handle Fortnite,
[04:05.620 --> 04:09.660]  but don't have to put trust on the client to do that.
[04:09.660 --> 04:12.720]  And from the perspective of game hackers,
[04:12.720 --> 04:17.200]  hacking will just become more of a process
[04:17.200 --> 04:18.680]  of finding logical bugs,
[04:18.680 --> 04:21.420]  rather than doing what we typically do now,
[04:21.420 --> 04:24.020]  which is exploiting those trust relationships.
[04:24.360 --> 04:26.220]  Well, that's interesting.
[04:26.220 --> 04:29.240]  So a slightly different angle of a question
[04:29.240 --> 04:31.760]  coming from Blackfoot over here.
[04:32.040 --> 04:35.100]  Why do you think there is so little security knowledge share
[04:35.100 --> 04:36.600]  between game companies?
[04:36.600 --> 04:38.480]  Example, little documentation
[04:38.480 --> 04:42.420]  and hardening of UE4 dedicated servers.
[04:44.540 --> 04:46.140]  That's a pretty good question.
[04:46.140 --> 04:48.160]  If I had to guess, it would just be because
[04:48.160 --> 04:52.440]  game engines are such big pieces of software
[04:52.440 --> 04:55.780]  that when you develop your own game engine,
[04:55.780 --> 04:58.500]  you're sort of going to try to hold it close to your chest.
[04:58.500 --> 05:01.580]  You don't really want to give your competitors
[05:02.520 --> 05:08.120]  a competing game engine the keys to the kingdom, so to speak.
[05:08.120 --> 05:10.540]  So architecturally, most game engines are built
[05:10.540 --> 05:11.860]  from the ground up.
[05:11.860 --> 05:13.680]  There's not a lot of shared code,
[05:13.680 --> 05:18.140]  and that's just because it's a big investment
[05:18.620 --> 05:20.860]  and no one wants to share that.
[05:20.880 --> 05:23.480]  It's sort of a boring business answer, I think,
[05:23.480 --> 05:26.740]  but it's really just Unreal and Unity
[05:26.740 --> 05:30.720]  and whoever else don't want to share their work with each other.
[05:31.200 --> 05:33.700]  So in your presentation,
[05:33.700 --> 05:35.760]  one of the things that you were showing
[05:35.760 --> 05:38.740]  was kind of like the teleporting and the fast running.
[05:38.800 --> 05:40.380]  I remember at one point in there,
[05:40.380 --> 05:42.600]  you're just kind of showing somebody running at the normal speed
[05:42.600 --> 05:46.660]  and then the exploit that you were able to find
[05:46.660 --> 05:48.840]  where somebody's zipping across the screen.
[05:48.980 --> 05:50.800]  In addition to running,
[05:50.800 --> 05:52.200]  do you think there are other things
[05:52.200 --> 05:54.520]  that people could use that kind of thing for?
[05:54.520 --> 05:57.500]  Maybe be able to shoot faster, shoot more?
[05:57.800 --> 05:59.780]  Maybe what other kind of things have you thought of
[05:59.780 --> 06:03.080]  that somebody could use that type of exploit for in their games?
[06:03.660 --> 06:04.780]  Yeah, absolutely.
[06:04.780 --> 06:06.880]  So with that particular bug,
[06:06.880 --> 06:10.440]  I found what I think is really interesting.
[06:10.440 --> 06:13.940]  It's basically a bug where you can use the unique properties
[06:13.940 --> 06:17.940]  of some special floating point values
[06:17.940 --> 06:22.100]  to basically confuse the server into doing something it shouldn't.
[06:22.100 --> 06:25.400]  And so I have actually tried basically that exact technique
[06:25.400 --> 06:29.660]  on other games, other commands and stuff like that.
[06:29.660 --> 06:34.020]  And you can usually get something unpredictable to happen.
[06:34.020 --> 06:35.260]  I think I mentioned in my talk,
[06:35.340 --> 06:37.440]  a lot of times it's not a good thing.
[06:37.440 --> 06:40.020]  A lot of times you're just harming yourself,
[06:40.020 --> 06:43.120]  but you can usually cause the game to do something it shouldn't.
[06:43.300 --> 06:48.580]  And so, yeah, I think these logical bugs,
[06:48.580 --> 06:51.600]  especially like mathematical bugs, if you can find those,
[06:51.600 --> 06:56.460]  are a really good way to exploit games
[06:56.460 --> 06:59.720]  because while the bugs aren't the most common,
[06:59.720 --> 07:01.440]  they are very predictable.
[07:01.440 --> 07:03.720]  They're not a memory corruption bug
[07:03.720 --> 07:05.980]  where you have to worry about layout of the memory
[07:05.980 --> 07:07.920]  and all those complicated things.
[07:07.920 --> 07:13.140]  And they tend to, I guess,
[07:13.140 --> 07:16.800]  slip by the architectural protection.
[07:16.800 --> 07:19.860]  So in that case, like the bug you talked about,
[07:19.860 --> 07:23.580]  Unreal Engine has a pretty robust way to prevent speed hacking.
[07:24.100 --> 07:28.120]  And using just a couple quirks of,
[07:28.960 --> 07:32.480]  basically, quirks of decimal numbers,
[07:32.480 --> 07:34.500]  you can cause it to do something it shouldn't.
[07:34.500 --> 07:36.780]  And that is super useful.
[07:36.780 --> 07:39.960]  So that particular kind of bug, I'd say, yes,
[07:39.960 --> 07:42.340]  definitely applies in other places.
[07:42.460 --> 07:45.840]  It's just a matter of looking for it.
[07:45.860 --> 07:49.180]  And I guess that's it.
[07:49.180 --> 07:51.200]  I don't know how I was going to end that sentence.
[07:51.240 --> 07:53.360]  No, I really liked what you showed there,
[07:53.360 --> 07:57.780]  especially the things that we find in other places
[07:57.780 --> 08:00.360]  across security and other types of hacking.
[08:00.360 --> 08:03.100]  You go, well, okay, let's divide by zero.
[08:03.100 --> 08:04.520]  Let's use not a number.
[08:04.520 --> 08:08.200]  Let's use these things that are the outsides
[08:08.200 --> 08:10.840]  of this language that's being used
[08:11.360 --> 08:15.420]  and see what happens when you throw it at the system.
[08:15.420 --> 08:17.580]  And it's just nice to see,
[08:18.280 --> 08:21.480]  in the niche that you found yourself in,
[08:21.660 --> 08:23.520]  a lot of the same techniques work.
[08:24.280 --> 08:27.580]  Yeah, I guess one other thing I like about that bug
[08:27.580 --> 08:30.800]  is that it's not something that's fixed by, say,
[08:30.800 --> 08:32.540]  oh, we're going to stop writing things in C
[08:32.540 --> 08:36.020]  and start writing them in Go or Rust or something.
[08:36.020 --> 08:39.940]  These are bugs that still exist even in,
[08:39.940 --> 08:42.480]  quote-unquote, safe languages.
[08:42.500 --> 08:46.280]  And I think in more than just video games,
[08:46.280 --> 08:49.340]  that's where this sort of exploitation is going.
[08:49.340 --> 08:51.980]  And that's why I like that bug so much.
[08:53.140 --> 08:56.560]  All right, so Hawkeye has another question for you.
[08:56.560 --> 08:59.780]  He asks, have you noticed any new trends
[08:59.780 --> 09:03.620]  of input validation in high-user games like Fortnite?
[09:04.460 --> 09:08.540]  Yeah, I mean, I keep going back to the same example,
[09:08.540 --> 09:11.540]  but Unreal Engine 4 uses a really,
[09:12.760 --> 09:16.560]  really robust system for validating user input
[09:16.560 --> 09:18.640]  and specifically user movement
[09:19.480 --> 09:22.820]  in a way that scales really well,
[09:22.820 --> 09:25.480]  but also basically eliminates your ability
[09:25.480 --> 09:30.340]  to manipulate your movement in any significant way.
[09:30.340 --> 09:35.340]  And so essentially the broad strokes are basically
[09:35.340 --> 09:41.380]  taking authority over your character's location,
[09:41.380 --> 09:42.760]  putting it on the server,
[09:42.760 --> 09:46.300]  and giving the client the possibility to call functions
[09:46.300 --> 09:49.360]  in order to request that you move.
[09:49.360 --> 09:52.780]  And that way, the server has the context to say,
[09:52.780 --> 09:54.680]  well, you're trying to move too fast.
[09:55.760 --> 09:57.400]  I'm not going to allow that.
[09:57.400 --> 10:01.200]  I'm going to limit movement to a specific range.
[10:01.200 --> 10:05.780]  And so really, I think the entirety of evolutions
[10:05.780 --> 10:09.540]  in the security of game engines recently
[10:09.540 --> 10:13.140]  has just been on giving more context to the server
[10:13.140 --> 10:15.320]  so we can say, well, that's not right.
[10:15.320 --> 10:17.560]  I'm going to stop that from happening
[10:17.560 --> 10:19.980]  and ensuring that the client doesn't have the trust
[10:19.980 --> 10:22.000]  to just overrule the server.
[10:22.000 --> 10:25.020]  I can't remember whether you said in your presentation
[10:25.020 --> 10:30.180]  if you've talked to the engine companies
[10:30.180 --> 10:33.140]  about these vulnerabilities and if they have fixed
[10:33.140 --> 10:35.820]  the exploits that you found.
[10:35.820 --> 10:38.440]  But if they do see somebody trying to send
[10:38.440 --> 10:42.240]  like your NAN, not a number, at the server,
[10:42.240 --> 10:44.260]  what types of things would you think
[10:44.260 --> 10:46.860]  that they should do to that?
[10:46.860 --> 10:49.300]  Should they kind of just adjust or ban?
[10:49.300 --> 10:52.420]  What are your thoughts for how people could...
[10:52.420 --> 10:53.880]  what should happen to them?
[10:54.300 --> 10:59.380]  Yeah, so three of the four bugs I talk about are fixed.
[11:00.540 --> 11:06.000]  And the speed hack one, the NAN one, was one of those.
[11:06.000 --> 11:07.580]  It was actually a pretty easy fix.
[11:07.580 --> 11:09.800]  They just put a tiny little check in there that says
[11:09.800 --> 11:12.520]  if this is NAN, just abort, get out of there.
[11:12.640 --> 11:15.060]  But in general, I would say
[11:17.220 --> 11:19.060]  what they should...
[11:20.040 --> 11:24.660]  I would recommend possibly that if you're a game engine developer
[11:24.660 --> 11:27.000]  or you're working on Unreal and you think,
[11:27.000 --> 11:31.400]  oh, this could be a problem, it's not unreasonable to just say
[11:31.400 --> 11:34.980]  you shouldn't be able to use NAN in any argument.
[11:34.980 --> 11:38.040]  That's not going to happen under normal circumstances.
[11:38.280 --> 11:41.320]  And just essentially eliminate that from the serialization
[11:41.900 --> 11:44.260]  and deserialization process.
[11:44.260 --> 11:47.220]  Unreal doesn't do that because it wants to consider itself
[11:47.220 --> 11:48.780]  sort of impartial to that.
[11:48.780 --> 11:53.640]  Whatever goes in one end is deserialized on the other end.
[11:54.000 --> 12:00.780]  But I think it would be a pretty reasonable assumption to say
[12:00.780 --> 12:04.040]  if you're getting certain types of, say, floating point numbers,
[12:04.040 --> 12:06.280]  this is blatantly invalid.
[12:06.280 --> 12:07.700]  And we can probably just toss it out
[12:07.700 --> 12:10.080]  before we even consider anything else.
[12:11.320 --> 12:15.780]  Just a general input validation on what's coming in.
[12:15.880 --> 12:17.720]  Typical boring stuff.
[12:18.560 --> 12:20.480]  Isn't it that way?
[12:20.540 --> 12:24.460]  Well, so I don't really want to give away the punchline
[12:24.460 --> 12:27.020]  to your presentation because it fits so well,
[12:27.020 --> 12:30.020]  but we'll just kind of hand wave that and say,
[12:30.020 --> 12:35.800]  so when you've been doing this, how often do you get booted
[12:35.800 --> 12:39.060]  from whatever game you're playing?
[12:39.060 --> 12:42.760]  Or how many times have you had your accounts banned?
[12:43.920 --> 12:46.040]  When you're building your own stuff,
[12:46.040 --> 12:48.820]  you get banned less than you might expect.
[12:48.820 --> 12:53.260]  I did a talk last year on hacking, basically, browser games.
[12:53.300 --> 12:58.440]  And for one of the demonstrations, I took a game.
[12:58.440 --> 13:01.260]  I don't want to say its name. I've done enough to them.
[13:01.560 --> 13:05.160]  But I took this game and it has a global scoreboard
[13:05.160 --> 13:10.700]  and I just set my score to 1, 3, 3, 3, 3, 3, 3, 3, something, 7,
[13:10.700 --> 13:12.780]  and username to HiDefCon.
[13:12.780 --> 13:14.600]  And they banned me pretty quickly.
[13:14.600 --> 13:16.760]  I think that was pretty obvious.
[13:16.840 --> 13:20.620]  But in general, if you're building your own game hacks,
[13:20.620 --> 13:23.240]  there is a pretty good chance you're going to get away with it.
[13:23.240 --> 13:25.520]  So I get banned pretty rarely.
[13:28.100 --> 13:30.620]  So congratulations or I'm sorry.
[13:30.940 --> 13:32.940]  However you feel about that.
[13:33.160 --> 13:34.540]  It's a mixed bag.
[13:35.560 --> 13:40.720]  Where do you also often kind of see the line here along the same,
[13:40.720 --> 13:43.840]  I guess similar to what Fallible was just talking about,
[13:43.840 --> 13:48.280]  where the old question about research versus going over the line,
[13:48.280 --> 13:52.720]  because essentially you are affecting other users, potentially,
[13:53.260 --> 13:54.960]  as well as that game engine.
[13:54.960 --> 13:59.300]  So where is kind of your line on how far you'll go with your research?
[13:59.360 --> 14:03.620]  Or is it because it's in the name of research, you'll just go all the way with it?
[14:03.620 --> 14:07.020]  I mean, I won't do anything that's, I think,
[14:07.020 --> 14:12.540]  directly affecting someone spending money or someone or anything like that.
[14:12.540 --> 14:15.860]  I'm not stealing items from people in online games.
[14:15.860 --> 14:17.660]  That certainly crosses the line.
[14:17.660 --> 14:20.600]  But, you know, if someone's in a lobby of a first person shooter
[14:20.600 --> 14:25.440]  and someone wall hacks through and, you know, no scopes them in the head,
[14:25.440 --> 14:28.720]  I don't think they've been significantly harmed in any way.
[14:28.720 --> 14:34.980]  So I think that is within moral bounds for me.
[14:34.980 --> 14:36.000]  Excellent.
[14:38.200 --> 14:42.420]  Can you explain some of the technical setup that you have
[14:42.420 --> 14:46.360]  in order to capture the data that you're sending across?
[14:46.360 --> 14:50.440]  And what tools are you using? What's your lab look like?
[14:50.440 --> 14:55.020]  Yeah, so working with Unreal Engine especially,
[14:55.020 --> 14:58.500]  I needed to actually buy a new desktop to do
[14:58.500 --> 15:02.020]  because on the laptop I was working on,
[15:02.020 --> 15:05.920]  it took most of the day to compile Unreal from source.
[15:05.920 --> 15:09.660]  And I was doing that several times a day.
[15:09.660 --> 15:13.660]  So that was not good math working out there.
[15:13.660 --> 15:18.320]  So essentially, I do all of my Unreal development on Linux,
[15:18.320 --> 15:22.780]  which is a little less supported, but it's just more comfortable for me.
[15:22.780 --> 15:28.940]  And the other, I guess the other thing that's really a challenge
[15:28.940 --> 15:32.960]  is the specifically Unreal source is so big
[15:32.960 --> 15:39.340]  that trying to open it in most like project editors is, it does not work.
[15:39.340 --> 15:44.440]  VS code gets by just a little bit, but even then it gets tripped up
[15:44.440 --> 15:48.240]  when you try to go to this function or something like that,
[15:48.240 --> 15:52.360]  it'll end up, it'll spin its wheels for five minutes and say,
[15:52.360 --> 15:55.520]  yeah, couldn't find it, even though you know it exists.
[15:55.520 --> 15:58.700]  So I wish I had a better setup.
[15:58.700 --> 16:01.180]  I'm sure people who do actual video game development
[16:01.180 --> 16:05.060]  have better experiences with building Unreal from source.
[16:05.060 --> 16:11.520]  But I guess my lab is just, it's a system 76 desktop
[16:11.520 --> 16:16.200]  with the highest boxes checked on everything,
[16:16.200 --> 16:19.580]  just so that I can compile Unreal as many times as I want
[16:19.580 --> 16:21.160]  and it doesn't take me all day.
[16:22.600 --> 16:26.600]  So in that way, you're looking at the guts of the code,
[16:26.600 --> 16:28.960]  you're really building it each time.
[16:28.960 --> 16:32.800]  It's not a situation of you're just capturing everything in Wireshark
[16:32.800 --> 16:35.840]  and modifying it somehow.
[16:36.400 --> 16:39.440]  No, I wish it was a little easier.
[16:39.440 --> 16:45.960]  With Unet, you can get away with just looking at the traffic in Wireshark.
[16:45.960 --> 16:50.220]  Unreal is pretty difficult because everything is like bit aligned,
[16:50.220 --> 16:53.260]  so you'll have a string that starts four bits in
[16:53.260 --> 16:55.080]  and just looks like gibberish.
[16:55.120 --> 16:57.960]  So you really do have to be looking at it at the low level
[16:57.960 --> 16:59.840]  to really make any sense of it.
[17:01.020 --> 17:02.320]  That makes sense.
[17:02.320 --> 17:05.440]  And how does somebody get started with that kind of thing?
[17:05.440 --> 17:09.520]  Because this sounds extremely technical and you have to know quite a bit.
[17:09.560 --> 17:12.240]  How does somebody, where would be the entry point
[17:12.240 --> 17:14.580]  if somebody was interested in this kind of research
[17:14.580 --> 17:17.700]  in order to start figuring these kinds of things out,
[17:17.700 --> 17:21.060]  or if they wanted to just even look at how games work?
[17:21.640 --> 17:24.840]  Yeah, well, I mean, all the code is out there for Unreal Engine,
[17:24.840 --> 17:28.740]  but I don't think that's something you should just jump straight into,
[17:28.740 --> 17:33.380]  especially if you're not pretty familiar with C++,
[17:33.380 --> 17:36.200]  because it is a complicated code base.
[17:36.200 --> 17:40.820]  I think the best thing you can do to understand hacking video games
[17:40.820 --> 17:43.300]  is to build them.
[17:43.400 --> 17:46.760]  It's sort of a, I don't know, cliche answer,
[17:46.760 --> 17:49.500]  but that is what teaches you, oh, this is how that works.
[17:49.500 --> 17:50.740]  This is how I'd write it.
[17:50.740 --> 17:55.420]  This is probably how it looks on the back end.
[17:55.540 --> 17:58.860]  Also, I would say if you're going to look at games
[17:58.860 --> 18:01.860]  written in a particular engine, Unity games are pretty good
[18:01.860 --> 18:07.100]  because they're usually built, well, they're built with C Sharp
[18:07.100 --> 18:10.800]  and they're typically easy to decompile back to C Sharp
[18:10.800 --> 18:14.720]  with something like DN Spy, if I'm pronouncing that correctly.
[18:14.720 --> 18:16.320]  However, that's verbalized.
[18:16.320 --> 18:20.000]  So you can actually look at the code of the game, modify it,
[18:20.000 --> 18:23.220]  see what happens, and basically hack games
[18:23.220 --> 18:28.480]  without too much actual binary reverse engineering
[18:28.480 --> 18:30.920]  or anything like that.
[18:31.620 --> 18:40.200]  So we got a question from Jay that I'm going to obscure this a little bit.
[18:40.200 --> 18:42.720]  The question is way too specific,
[18:42.720 --> 18:50.420]  so let's go more along the lines of where else would be interesting to look?
[18:50.420 --> 18:54.920]  If you were done with the research that you've done so far
[18:54.920 --> 18:57.700]  and you were looking for a new product,
[18:57.700 --> 19:02.340]  what would be the things that would draw you to a new product?
[19:03.900 --> 19:09.800]  Yeah, so one thing I would say is that when you look at Unity,
[19:09.800 --> 19:14.360]  there are a lot of different multiplayer solutions.
[19:14.360 --> 19:18.680]  So I looked at UNet, which is sort of the... it's provided by Unity,
[19:18.680 --> 19:22.460]  but there are third-party solutions that are pretty common.
[19:22.820 --> 19:25.660]  Photon, Mirror, I haven't looked at those at all,
[19:25.660 --> 19:28.480]  and I think that there's a pretty solid chance
[19:28.480 --> 19:31.320]  that the same kind of bugs apply there.
[19:31.460 --> 19:34.800]  And then I think most of the research I did,
[19:34.800 --> 19:38.560]  obviously I'm just looking at the core engines for games,
[19:38.560 --> 19:42.160]  but looking at specific games, you can find these exact same bugs.
[19:42.160 --> 19:46.880]  They just may not apply to other games.
[19:46.880 --> 19:49.180]  So I think most of this research still applies.
[19:49.180 --> 19:52.160]  It just needs to be targeted either at different games
[19:52.160 --> 19:55.980]  or different multiplayer protocols, even different game engines.
[19:55.980 --> 19:58.380]  Game Maker, there are...
[19:58.380 --> 20:00.900]  Well, I think I've looked at the two more common game engines.
[20:00.900 --> 20:02.960]  There are other engines out there.
[20:04.100 --> 20:07.500]  In other words, just find another big target and play,
[20:07.500 --> 20:09.780]  or just go and learn something.
[20:09.780 --> 20:13.240]  If you happen to be using a game, then this might be a good opportunity.
[20:14.540 --> 20:16.260]  Hawkeye Dank asked another question
[20:16.260 --> 20:20.220]  about the outcome of your work,
[20:20.220 --> 20:22.860]  and he wants to know if you've managed
[20:22.860 --> 20:24.820]  to pull any bounties for this.
[20:25.720 --> 20:28.540]  Yeah, I turned down bounties for a few things
[20:28.540 --> 20:30.500]  because I wanted to talk about them.
[20:30.500 --> 20:33.880]  If I was really min-maxing it, I probably would have accepted bounties
[20:33.880 --> 20:37.300]  for a few more, but you never know.
[20:37.760 --> 20:41.380]  So yes, Unity and Epic Games
[20:41.380 --> 20:43.860]  were both really good about this.
[20:45.400 --> 20:46.680]  Epic has
[20:46.680 --> 20:48.640]  HackerOne program.
[20:48.640 --> 20:51.460]  Unity, you want to just go straight to their security
[20:51.460 --> 20:55.380]  at unity3d... whatever, I don't want to give you the wrong email.
[20:55.380 --> 20:57.440]  Security at email address.
[20:57.440 --> 20:59.800]  But both were awesome to work with.
[20:59.800 --> 21:03.780]  I would highly recommend it,
[21:03.780 --> 21:06.380]  and yes, there is definitely money to be made.
[21:07.120 --> 21:09.060]  And you've looked at the Unreal
[21:09.060 --> 21:12.380]  and Unity engines. Are there any others that you've looked at
[21:12.380 --> 21:14.200]  or found bugs with?
[21:15.660 --> 21:18.180]  I have done a fair amount of reverse engineering
[21:18.180 --> 21:21.620]  on GameMaker, which is one of the
[21:21.620 --> 21:24.780]  more common engines, certainly less than Unity
[21:24.780 --> 21:28.200]  or Unreal. Not from a security perspective,
[21:28.200 --> 21:31.240]  just from a how do I hack this game
[21:31.240 --> 21:33.840]  or how do I mod this game
[21:34.840 --> 21:36.040]  aspect.
[21:36.400 --> 21:40.060]  I guess one of the problems is that some of these
[21:40.060 --> 21:43.400]  smaller engines don't provide you the same
[21:44.140 --> 21:46.100]  tools. They may not have an entire
[21:46.100 --> 21:49.060]  networking solution, so there's less
[21:49.060 --> 21:52.180]  places for bugs to be hiding. That's why
[21:52.180 --> 21:55.680]  I think Unity and Unreal were such good targets.
[21:55.680 --> 21:58.680]  But I do think there is opportunity for bugs
[21:58.680 --> 22:01.740]  in those other engines. I just really haven't done the work
[22:01.740 --> 22:03.100]  in that context.
[22:03.100 --> 22:06.980]  And have you also looked at the individual games itself?
[22:06.980 --> 22:09.500]  And what's really the difference between trying to find
[22:09.500 --> 22:13.540]  vulnerabilities in the game engine and a specific game?
[22:14.300 --> 22:16.540]  I guess usually the difference
[22:16.540 --> 22:19.320]  is whether or not you're going to have an easily accessible
[22:19.320 --> 22:22.300]  source. So Unreal Engine games,
[22:22.300 --> 22:26.460]  like reverse engineering an actual released Unreal Engine game
[22:26.460 --> 22:29.200]  can be pretty tedious because you're not looking at the source.
[22:29.200 --> 22:32.320]  You're not typically even looking at something with symbols.
[22:32.320 --> 22:34.920]  You're just looking at a gigantic blob in
[22:34.920 --> 22:38.020]  Ida or Ghidra. But I have
[22:38.020 --> 22:41.440]  had some success there. I don't want to burn bridges, so I'm
[22:41.440 --> 22:43.720]  just going to leave it at that.
[22:44.320 --> 22:47.380]  But I guess the main
[22:47.380 --> 22:48.960]  difference is just how much
[22:49.760 --> 22:53.740]  effort goes into reverse engineering.
[22:56.540 --> 22:57.460]  This sounds
[22:57.460 --> 23:00.160]  like a pretty specific question, but we'll toss it out there.
[23:00.160 --> 23:03.080]  So thoughts on cheat engine or memory scanners
[23:03.080 --> 23:05.560]  as a toolkit from beginners? That's from
[23:05.560 --> 23:07.080]  Ethics.
[23:08.460 --> 23:11.620]  Cheat engine is awesome. It's how I started learning.
[23:11.620 --> 23:14.040]  My talk last year was on essentially applying
[23:14.880 --> 23:17.780]  a lot of the methods and techniques of cheat engine to
[23:17.780 --> 23:21.180]  WebAssembly, so games in your browser, basically.
[23:21.180 --> 23:23.760]  So I think cheat engine is great. It is
[23:24.080 --> 23:26.080]  a problem that as
[23:26.660 --> 23:29.840]  game engines get more secure,
[23:29.840 --> 23:31.800]  those techniques don't work as well.
[23:31.800 --> 23:35.820]  To give a general example, what cheat
[23:35.820 --> 23:38.700]  engine generally does, what you're usually doing with it, is
[23:38.700 --> 23:41.780]  you look for something like your health and you say, OK, I'm looking
[23:41.780 --> 23:44.600]  for something in memory that's 100.
[23:44.600 --> 23:47.800]  Then I take some damage and say, OK, of all those values that used
[23:47.800 --> 23:50.460]  to be 100, which one is now 87
[23:50.460 --> 23:53.440]  or something like that? And that helps you find
[23:53.440 --> 23:56.620]  the value in memory that corresponds to your health.
[23:56.620 --> 23:58.940]  And then you can manipulate that.
[23:59.360 --> 24:01.900]  Give yourself more health, whatever.
[24:02.200 --> 24:05.520]  But as games take trust away from the client,
[24:05.520 --> 24:08.680]  that process doesn't work anymore. You can manipulate your health
[24:08.680 --> 24:11.540]  client side, but the server still knows you have 87
[24:11.540 --> 24:14.320]  health, not 10,000 or whatever.
[24:14.400 --> 24:17.660]  So, I do think
[24:17.660 --> 24:20.640]  if you're looking at the right games, that is a great way
[24:20.640 --> 24:23.520]  to get into game hacking and understand those basic concepts.
[24:23.520 --> 24:25.900]  But it's not going to work on
[24:26.840 --> 24:29.360]  PUBG or something where someone has
[24:29.360 --> 24:32.240]  put a conscious effort into making it secure
[24:32.240 --> 24:34.920]  and something that's come out in the last
[24:35.340 --> 24:38.060]  five years, a decade, something like that.
[24:38.060 --> 24:41.040]  And how much now are the developers trying to go
[24:41.040 --> 24:43.400]  with more, I don't know if it's the right term for it,
[24:43.400 --> 24:47.100]  the thin client, so that people can't really
[24:47.100 --> 24:49.860]  make changes in the client side or
[24:49.860 --> 24:53.300]  in their mobile device phone and give myself a million lives
[24:53.300 --> 24:56.380]  or a million gems or coins or anything like that
[24:56.380 --> 24:58.940]  and trying to keep all of that on the server. How much of
[24:58.940 --> 25:02.280]  that do you kind of see with the games
[25:02.280 --> 25:05.780]  and the servers? In my experience,
[25:05.780 --> 25:08.660]  it's really just whatever the engine does,
[25:08.660 --> 25:11.180]  the developer will follow. Unreal
[25:11.720 --> 25:14.260]  sets you up really well to
[25:14.780 --> 25:17.680]  build an architecture where those game hacks
[25:17.680 --> 25:20.740]  don't work or are exceptionally difficult.
[25:20.740 --> 25:23.960]  And so you see developers doing a pretty good job.
[25:24.460 --> 25:26.780]  Unity does not set you up quite
[25:26.780 --> 25:29.600]  as well from the start, and so you'll see the majority
[25:29.600 --> 25:32.260]  of those, I guess we'll call
[25:32.260 --> 25:36.060]  simple attacks, do often work.
[25:36.320 --> 25:38.320]  That's not to say that you can't build
[25:38.640 --> 25:41.380]  a secure architecture on Unity. It just
[25:41.380 --> 25:44.140]  means that Unity's not doing the work
[25:44.140 --> 25:47.540]  for you, and like I said, developers
[25:47.540 --> 25:50.780]  will typically follow what the engine does.
[25:50.780 --> 25:53.520]  So as the core software, as
[25:53.520 --> 25:57.280]  the water level rises, developers get better at it as well.
[25:57.360 --> 25:59.360]  Cool. Is there anything that
[25:59.360 --> 26:02.340]  you didn't get a chance to put into your presentation that
[26:02.340 --> 26:05.320]  is additional research that you might have done, or are there any
[26:05.320 --> 26:08.360]  kind of other areas that you think other people might be able
[26:08.360 --> 26:10.800]  to add on to the research that you've done?
[26:11.320 --> 26:14.480]  Yeah, so a couple things come to mind. The first
[26:14.480 --> 26:17.600]  is the floating point bugs I talked about.
[26:17.600 --> 26:19.720]  I think that can apply a lot.
[26:19.980 --> 26:22.980]  I very briefly mentioned this, but
[26:22.980 --> 26:26.400]  that attack does actually apply to Unity.
[26:26.400 --> 26:29.160]  The difference is that you don't need to speed
[26:29.160 --> 26:31.840]  hack Unity. You can just, or at least by
[26:32.400 --> 26:35.260]  using the core components that are provided for you, you can just
[26:35.260 --> 26:38.480]  tell it, I'm at x, y, z. And if you tell it
[26:38.480 --> 26:41.360]  I'm at nan, nan, nan, you get
[26:41.360 --> 26:44.240]  teleported to this weird dimension where everything is
[26:44.240 --> 26:47.680]  infinitely small. It's kind of cool. It's not very useful.
[26:47.920 --> 26:50.660]  So I think that kind of attack applies
[26:51.220 --> 26:53.420]  to a lot of things, and I'd like to see
[26:53.420 --> 26:56.500]  where else it goes. Something else that I feel
[26:56.500 --> 26:59.640]  like I wanted to do, but I didn't quite
[26:59.640 --> 27:02.280]  find all the pieces, was I found
[27:02.520 --> 27:05.440]  a number of memory corruption bugs, like buffer
[27:05.440 --> 27:08.560]  overflow, stuff like that.
[27:08.560 --> 27:11.540]  And a lot of those seemed like
[27:11.540 --> 27:14.300]  they would be good for turning something into remote code
[27:14.300 --> 27:17.540]  execution, but the problem that I was always running into
[27:17.540 --> 27:20.420]  is I couldn't imagine a situation
[27:20.420 --> 27:23.600]  where you were looking at a game server and you knew what it
[27:23.600 --> 27:26.400]  looked like on the back end. So a memory corruption exploit
[27:27.160 --> 27:29.160]  requires some knowledge of
[27:29.160 --> 27:32.060]  memory, of the layout of memory, where
[27:32.980 --> 27:35.600]  code is, gadgets, stuff
[27:35.600 --> 27:38.820]  like that. And while you may have a copy of the client, you don't have a
[27:38.820 --> 27:41.820]  copy of the server. And so even if you can bypass
[27:41.820 --> 27:45.040]  all those difficult protections, ASLR,
[27:45.040 --> 27:47.520]  stuff like that, I just couldn't imagine
[27:47.680 --> 27:50.680]  a scenario where I could turn
[27:50.680 --> 27:53.520]  one of these into an RCE exploit on
[27:53.520 --> 27:56.440]  an actual server. And so that's why I
[27:56.440 --> 27:59.680]  felt a little disappointed in myself, because I had what
[27:59.680 --> 28:02.800]  felt like good bugs, but it didn't
[28:02.800 --> 28:04.700]  feel practical to turn them into
[28:05.500 --> 28:08.540]  an exploit that would work in the real world.
[28:08.660 --> 28:11.560]  So I would love to see someone actually pull that off.
[28:12.380 --> 28:14.540]  So we are right down
[28:14.540 --> 28:17.720]  to the bare end of this thing. So two questions.
[28:17.720 --> 28:20.500]  One is, would you be willing to
[28:20.500 --> 28:23.600]  post places that people can find you later, whether that
[28:23.600 --> 28:26.320]  be an email or a website or Twitter?
[28:26.340 --> 28:29.780]  We can do that in the TrackOne channel at the end of this.
[28:29.780 --> 28:32.600]  And two, if you were to leave us
[28:32.600 --> 28:35.300]  with a call to action, something you would like us to
[28:36.040 --> 28:38.880]  consider as we're moving forward. I've been asking this of everybody.
[28:38.880 --> 28:41.640]  I kind of like this question. What should we take away from
[28:41.640 --> 28:45.040]  this and in our own work? And how can we
[28:45.040 --> 28:48.660]  translate your stuff into ours? What would you want us to do?
[28:49.240 --> 28:50.700]  Yeah, so absolutely.
[28:50.700 --> 28:54.060]  I will post my GitHub. It is on the slides
[28:54.060 --> 28:57.600]  as well, but I'll post it again. My email address is there too.
[28:57.600 --> 28:59.780]  Hit me up. I've already had a few people.
[28:59.780 --> 29:02.480]  I've had a couple of really interesting conversations, so I really
[29:02.480 --> 29:05.560]  appreciate it when people reach out. And
[29:05.560 --> 29:08.800]  I don't know. If I could ask for anything,
[29:08.800 --> 29:11.560]  it would be that if you're
[29:11.880 --> 29:15.320]  a security person, you work pen testing or whatever,
[29:15.320 --> 29:17.760]  try hacking video games. It's fun.
[29:17.760 --> 29:20.680]  I know you probably like video games because you're a nerd
[29:20.680 --> 29:23.340]  and you're at DEF CON. So am I.
[29:23.340 --> 29:26.380]  Try it. It's rewarding.
[29:26.740 --> 29:29.700]  It gets your adrenaline pumping. And getting banned
[29:29.700 --> 29:32.720]  is fun too. So that's my
[29:32.720 --> 29:35.720]  recommendation. If you haven't ever gotten banned from a
[29:35.720 --> 29:38.540]  video game, give it a shot. Awesome.
[29:38.580 --> 29:41.320]  Well, thank you so much for doing this, Jack. Appreciate you
[29:41.320 --> 29:44.840]  taking the time to be with us and really enjoyed your presentation.
[29:44.840 --> 29:47.760]  Hopefully everybody else goes and checks that out.
[29:47.760 --> 29:51.280]  So thank you so much. Yeah, thank you guys. This was fun.
[29:51.920 --> 29:53.880]  All right. We will be back
[29:53.880 --> 29:56.280]  in about 30 minutes with another speaker.
